High availability systems (also known as HA systems) are systems that are implemented primarily for the purpose of improving the availability of services which the systems provide. Availability can be expressed as a percentage of time during which a system or service is “up”. For example, a system designed for 99.999% availability (so called “five nines” availability) refers to a system or service which has a downtime of only about 0.44 minutes/month or 5.26 minutes/year.
High availability systems provide for a designed level of availability by employing redundant nodes, which are used to provide service when system components fail. For example, if a server running a particular application crashes, an HA system will detect the crash and restart the application on another, redundant node. Various redundancy models can be used in HA systems. For example, an N+1 redundancy model provides a single extra node (associated with a number of primary nodes) that is brought online to take over the role of a node which has failed. However, in situations where a single HA system is managing many services, a single dedicated node for handling failures may not provide sufficient redundancy. In such situations, an N+M redundancy model, for example, can be used wherein more than one (M) standby nodes are included and available.
As HA systems become more commonplace for the support of important services such as file sharing, internet customer portals, databases and the like, it has become desirable to provide standardized models and methodologies for the design of such systems. For example, the Service Availability Forum (SAF) has standardized application programming interfaces (APIs) to aid in the development of portable, highly available applications. As shown in the conceptual architecture stack of FIG. 1, the AIS 10 is intended to provide a standardized interface for the HA middleware 16 to support HA applications 14. As described below, each set of AIS functionality is associated with an operating system 20 and a hardware platform 22. The reader interested in more information relating to the AIS standard specification is referred to Application Interface Specifications (AIS), Release 5, which is available at www.saforum.org, the disclosure of which is incorporated here by reference.
Of particular interest for the present application is the Availability Management Framework (AMF), which is a software entity defined within the AIS specification. According to the AIS specification, the AMF is a standardized mechanism for providing service availability by coordinating redundant resources within a cluster to deliver a system with no single point of failure. The AMF provides a set of application program interface (API) functions which are used, among other things, to set the states of components within a cluster and to determine the health of those components. The components are also provided with the capability to query the AMF for information about their state. An application which is developed using the AMF APIs and following the AMF system model leaves the burden of managing the availability of its services to the AMF. Thus, such an application does not need to deal with dynamic reconfiguration issues related to component failures, maintenance, etc.
The AIS standard also defines the information model (IM) for applications to be controlled by AMF. According to this IM, a service unit (SU) as a logical entity that aggregates a set of components, thereby combining their individual functionalities to provide a higher level service. A service unit can contain any number of components, but a particular component can be configured in only one service unit. Since each component is always enclosed in a service unit, from the AMF's perspective, the service unit can be considered the incremental unit of redundancy in the sense that it is the smallest logical entity that can be organized into groups in a redundant manner to provide and protect the service instances.
A service group (SG) is defined within the AMF information model as a logical entity that groups one or more SUs in order to provide service availability for a particular set of service instances according to a particular redundancy model. The AMF information model also defines an application as being a logical entity that contains one or more SGs. An application combines the individual functionalities of the constituent service groups to provide a higher level of service. From a software administration point of view, this grouping into an application reflects the set of SUs and contained components that are delivered as a consistent set of software packages to the AMF environment. Within this environment, by introducing the software management framework (SMF), the AMF information model was extended with types that allow the characterization of software developed for SAF systems, e.g., software which is used to provide HA services managed by the AMF.
This software can typically be deployed in different configurations depending on, for example, the characteristics of the system it is deployed on, the number of nodes and their characteristics, the capabilities of the AMF implementation and the requirements put on the provided services. Thus, a software vendor can describe their software such that it would allow for the widest possible usage by describing various AMF related characteristics of the software. Based on this a system integrator has to produce a particular configuration for the system the software is deployed on. However, none of the current SAF specifications define how to generate the information model, i.e., the configuration to be used by an AMF implementation in a particular system for a particular application. Therefore, one option for creating an information model would be to create it manually. Considering the potential for an AMF configuration file to have hundreds if not thousands of lines of code to be properly defined, creating a configuration file in a manual manner will be time consuming and prone to errors.
Accordingly, it would be desirable to provide systems and methods automating the generation of configurations for an AMF system or process.